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Housekeeping with cron 




by Don Kuenz 

Solaris includes a background 
job scheduler named cron, 
which allows you to periodi- 
cally run housekeeping shell scripts 
to keep your system in top shape. 
Housekeeping often includes: back- 
ing up file systems, detecting nearly 
full file systems, removing unwanted 
files, and trimming logs. In this ar- 
ticle, we'll show you how to use 
cron and show you a couple of use- 
ful housekeeping scripts that you 
can use as a starting point for your 
own scripts. Although both scripts 



Figure A 



in this article use the Bourne shell, 
you're free to use most any com- 
mand within cron. 

For most of us, the best time to 
perform housekeeping is outside of 
normal business hours. It's always a 
good idea to invest in an Uninter- 
ruptable Power Supply (UPS) to 
protect your computer from unex- 
pected gaps in electrical power. 
When you use cron, the UPS be- 
comes mandatory. You also need 
access to root if you plan to use the 
scripts described in this article. 
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root crontab should be used to perform accounting data collection. 

rtc command is run to adjust the real time clock if and when 
ight savings time changes. 
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command 

0,4 /etc/cron. d/1 ogchecker 

6 /usr/lib/newsyslog 

/usr/lib/fs/nfs/nfsfind 
* [ -X /usr/sbin/rtc ] SS /usr/sbi n/rtc -c > /dev/null 2>ai1 

0,2,3,4,5,5 [ -X /usr/local/bin/daily.sh ] && /usr/local/bin/daily.sh 
1 [ -X /usr/local/bin/weekly.sh ] && /usr/1 ocal /bi n/«eekl y. sh 
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This is the content of our root account crontab. 



Using cron 

By default, Solaris starts a cron daemon in 
the /etc/rcl.d/K70cron startup script. Nor- 
mally, cron reads tables found under / var/ 
spool/ cron/ crontabs and logs output to 
/ var/cron/log. / var/ spool/cron/cronttab 
contains one table named after each user 
who enables and uses cron. A table is little 
more than a specially formatted text file. 
Figure A, on the cover, shows the content 
of a typical table. 

Each row of a cron table contains six col- 
umns. The first five columns specify when a 
command will launch, while the command 
itself appears in column six. You must keep in 
mind your host's time zone when you specify 
hours and minutes. Our host happens to use 
Greenwich Mean Time (GMT), but your host 
may very well use a different time zone. 



Both of our housekeeping scripts appear 
at the end of the root crontab, after Solaris' 
four default entries. Figure B shows a daily 
script named /usr/ local /bin /daily, which is 
scheduled to launch every day except Tues- 
day at 10:00 GMT (3:00 AM Mountain Time). 
Figure C shows a weekly script named 
/usr/local/bin/weekly which is sched- 
uled to launch on Tuesday at 10:00 GMT. 

Normally, cron mails both standard out- 
put and errors from a command to the owner 
of the crontab. We prefer to onJy see errors, so 
we route each script's standard output to 
/ dev/ null. That way, root only receives an 
E-mail when something goes wrong. 

Although you might be tempted to di- 
rectly edit cron tables with an editor, Solaris 
expects you to use a command named 
crontab to change cron tables. The partial 
syntax of crontab follows: 
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tt!/bin/sh 
tt 

tt Daily housekeeping script, 
tt 

PATH=$PATH:/usr/local/bin 
expnrt PATH 
echo ^date^ 
tt 

tt Set these variables to the number of days you'll allow unused files to hang 
tt around. 

max Last Access=+0 
maxLastHodi f i cati on=+£i 
fl * 

tf Set this variable to rm command (handy for script debugging), 
tt 

ttrmComraand-Vbin/ls -Id' 
riiiCommand='/bin/rni -f 
tt 

tt Remove core dumps, unnamed binaries, objects, and temporary files with an 

tt access time greater than maxLastAccess days. 

tt 

find /export/home -xdev 'C -name core -o -name a. out -o -natne '*.o' \ 

-0 -name 'tt*' -o -name '.tt*' -o -name '*.CKP' -o -name '.nfs*' ')' \ 
-atime SmaxLastAccess -exec SrmCommand £} ';' 

tt 

tt Remove backup vi files with a modification time greater than 

tt naxLastHodification days. 

tt 

find /var/preserve/* -mtirae $maxLastl1odification -exec SrtnComiiiand {} ';' 
tt 

tt Remove left-over. Samba print files CWinXX host names are: dionysus, cyclops, 

tt charybdis, and ares). 

tt^ 

find /tmp/* 'C -name 'dionys.*' -g -name 'cyclop.*' -o -name 'charyb.*' \ 
-0 -name 'ares.*' -o -name Ipq.* ')' \ 
-atime SmaxLastAccess -exec $rmCommand {} ' •/ 

tt 

tt Remove directories under /tmp with access times greater than maxLastAccess. 
tt 

find /tmp/* 'C ! -name . ! -name lost+found ')' -type d \ 
-mtime $naxLastAccess -exec $rmCommand O ';' 

tt 
tt 

tt Report on any file systems, which are at least 9C% full, 
tt 

df -k I awk 'NF == 6 SS $5 >= "go*" {printf "File system %s is *s 

full .\n",$1 ,$5}' 

tt 

tt Backup file systems, which are most likely to change on a daily basis, 
tt 

echo "Backuping up Hephaestus" 
cd / 

fflt -f /dev/rmt/1 erase 
umount /export/home 

ufsdump Ocuvf /dev/rmt/1 /dev/rdsk/cOdOs4 

mount /export/home 

mt -f /dev/rmt/1 offline 
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tt!/bin/sh 
tt 

tt Weekly housekeeping script, 
tt 

PATH=$PATH : /usr/l ocal /bi n 

export PATH 

tt 

tt How many logs do you want to keep? 
# 

maxLogs=5 
tt 

tt Set this variable to rm command Chandy for script debugging), 
tt 

ttrmCommand='/bin/ls -Id' 
rmCommand='/bin/rin -f 
tt 

tt A function to archive and remove logs 
tt 

archive Log C) 
{ 

tt $1 = path a file name of log 
dnanie=''di rname $1 
bname=^basename $1 - 
fname='$1 

f n am e D at 6"' $ f n am e . dat e + " «y*m%d . *H*H " ' 
tt remove link, keeping oldfile with date 
rm -f $fname 
- tt create new link 

touch $fname 
In Sfname $fnameDate 

tt only keep the newest maxLogs files, remove older fileCs) 

for oldFname in "Is -It $fname.*" 

do 

if [ "echo $i|«c -c" -gt $maxLogs ] 

then SrmCommand SoldFname 

fi 

i="echo Si"x 

done 

tt 

tt call archiveLog once for each log you wish to archive 
tt 

archiveLog /var/adm/aculog 
archiveLog /var/adm/messages 
archiveLog /var/adm/sulog 
archiveLog /var/adm/vold.log 
archiveLog /var/adm/wtmp 
archiveLog /var/adm/log/asppp. log 
archiveLog /var/log/syslog 
archiveLog /var/cron/log 
archiveLog /var/saf/_log 
archiveLog /var/saf/zsmon/log 
tt 

tt Backup file systems, which are most likely to change on a weekly basis, 
tt 

cd / 

ufsdump Ouvf /dev/rmt/On /dev/rdsk/cOdOs4 
ufsdump Ouvf /dev/rmt/On /dev/rdsk/cOdOs? 
ufsdump Ouvf /dev/rwit/On /dev/rdsk/c0d0s12 
ufsdump Ouvf /dev/rmt/On /dev/rdsk/c0d0s11 
mt -f /dev/rmt/0 offline 



II 



This is the content of our/usr/local/bin/daily.sh. 



This is the content of our /usr/local/bin/weekly.sh. 



crontab [-e] [-1 ] 

The -e option tells crontab to edit your 
table, while the - 1 option tells it to list your 
table. When you use the -e option, crontab 
defaults to using the rather cryptic ed pro- 
gram as an editor. A better solution is to tell 
it to use your favorite editor by setting an 
environmental variable named EDITOR to 
the name of your favorite editor before you 
invoke crontab: 

EDITOR=/usr/openwin/bi n/textedi t 
export EDITOR 
crontab -e 

If you forget to export an environment 
variable named EDITOR beforehand, just 
remember to type the letter cj at your first 
input opportunity. At that point, q causes ed 
to quit without saving. 

A daily script 

Our daily housekeeping script removes un- 
wanted files, lists file systems with less than 
10 percent free space, and backs up files that 
are most likely to change on a daily system. 
On our host, the /home file system is most 
likely to change each day. Although other 
file systems will also change during a week, 
we're willing to expose the other file systems 
to potential data loss based on the notion 
that it's easy to find and re-install recently 
acquired data. For newly acquired, precious 



data, we manually perform an immediate 
backup outside of cron. 

Unwanted files accumulate in a variety 
of ways. The kernel creates a core dump 
whenever something unexpected happens. 
Samba can create temporary print files that 
hang around until a reboot. Programmers 
tend to create object files, which they may 
forget to remove. Our daily script looks for 
and removes all of these types of files. 

A weeiciy script 

Our weekly housekeeping script trims log 
files and backs up all file systems that are 
likely to change. This includes every file 
system except /, /var, and /usr. 

Log files can grow until they com- 
pletely fill your file system. The first part 
of weekly.sh keeps log sizes down by 
trimming them. When weekly.sh trims a 
log, it creates an empty file using the de- 
fault name of the log file with the date 
and time suffix following. Then, it creates 
a link with the default name pointing to 
the current log. 

Summary 

Solaris hosts need periodic housekeeping 
to stay in top shape. Cron is a great tool 
for starting periodic jobs outside of normal 
business hours. 

Don Kuenz is a computer consultant. You 
can contact him at gtcs.com/assoc/ks/don. 
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IPC with Doors on Solaris 2.6 



by Abdur Chowdhury 

Doors is a fast IPC (InterProcess Com- 
murucation) call application program- 
ming interface (API) used in Solaris 2.5 
and 2.6. The Doors API has been documented 
for general use since Solaris 2.6. The Doors 
concept originated from the "Lightweight 
Remote Procedure Call"^ in the late 1980's. 
Sim's research operating system. Spring, then 
used those research ideas. The Spring operat- 



ing system used Doors as a method of storing 
object state and interfaces between domains. 
Spring was the testing bed for many of Sim's 
new additions to its commercial operating 
system. Today, Doors is an important topic of 
discussion because it's the fastest IPC mecha- 
nism available for Solaris. In this article, we'll 
discuss the concept of Doors on Solaris and 
the Doors API: A simple client/server. 
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The Doors concept 

The concept of Doors is very simple. When 
the cUent process makes a request from the 
server using door_ca U ( 3x ), the Doors h- 
brary creates a shuttle. The shuttle contains 
information for the server on the client 
pid, group, signals, and scheduling group. 
The shuttle^ puts the client process in the 
sleep state and the server in the run state. 
The server wakes and creates a new thread 
to handle the client's request. The server 
processes the information, returns the 
shuttle, destroys the thread, and puts the 
server in the sleep state and the client in 
the run state. 

Wliy is this IPC mechanism better than 
other IPCs? The above procedure is conceptu- 
ally the same as a protecting shared memory, 
an RCP call, or even a pipe. The advantages 
of Doors are found in the kernel. The Solaris 
2.6 kernel has the ability to run the client's 
thread in the servers' process space without 
an expensive context switch. The Solaris ker- 
nel can make optimizations for zero I/O cop- 
ies between the server process and the client 
process space by simply mapping pages of 
memory to both processes. 

We can use a synchronization object 
called a shuttle to transfer information from 
the client space to the server space — Uke sig- 
nahng information and procfs operations — 
we can use a synchronization object called a 
shuttle. The shuttle is responsible for mark- 
ing the current thread as sleeping and mark- 
ing the server thread as running. Then, it 
passes control directly to the server thread. 

Table A lists Sun's published timings 
comparing Doors to other IPC mechanisms. 
The timings are for SPARCstation 10 (dual 
processor, 40 MHz SuperSPARCTM 
processors). 



Table A: IPC Timings from Sun[2] 
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The Doors API 

The Doors API consists of eight Door calls 
and uses two related calls, f attach(3) and 
f d e t a c h ( 3 ) . We'll give you a brief overview 
of the API and develop a simple client and 
server application to demonstrate use of the 
Doors API. 

First, the user-level library, libdoor.so, 
implements the Door API. Any process 
can become a Door server. We can create 
a Door interface by using the door_create 
function. Now, this call returns a Door 
descriptor that's similar to a file descrip- 
tor. Next, the kernel provides the descrip- 
tor as the return value of door_create. In 
addition, the kernel keeps track of the 
process and Door descriptor pairs to en- 
sure that a process can't fabricate a false 
Door descriptor. The door_create call sim- 
ply sets up the call back function or the 
exported function entry point. Then, the 
API mandates a specific argument set for 
the Door function that you write. 

Although this may seem restrictive, the 
API really provides all the needed constructs 
to pass data — including Door descriptors. 
The ability to pass Door descriptors from 
process A to process B gives this API a tre- 
mendous amount of flexibility. You can pass 
file descriptors from one process to another 
with Doors. 

Now, the serving process must export 
the interface for other processes to use. The 
concept of creating yet another naming ser- 
vice isn't a good software practice, so the 
process must export its interface as part of 
the file system, much like named pipes or 
fifos are used. A process uses the f a t f a c h 
system call to attach a Streams-based Door 
descriptor to a file system name space object. 

Next, a server creates a Door export 
via the file space with fattach and waits 
for clients to request services. The Door 
API handles the actual creation of server 
threads. This paradigm provides simple 
client/ server architecture with thread 
support. 

The client process only needs to open 
the file created by the server process. The 
chent will receive a Door descriptor instead 
of a file descriptor, and the client simply 
calls door_ca 1 1 with the new Door descrip- 
tor. Then, the Door library takes over for 
the inter-process communication. 



All door_ca 1 1 s have the same calling ar- 
guments, a Door descriptor and the address 
of a door_arg_t structure. The door_arg_t 
structure contains the passing data, the size 
of the data, any Door descriptors that need 
to be sent, and the memory buffer for the re- 
turning results. Because all calls to door_ca 1 1 
are the same, no Interface Declaration Lan- 
guage (IDL) is needed to define the interface 
between the client and server processes. It's 
the responsibility of both the client and server 
to agree on the information format. 

The server calls the door_return function 
when it has completed the client's request. 
The arguments for door_return are a subset of 
the door_ca 1 1 function. The server process re- 
turns the data with the door_re turn call. 

Remaining Door calls 

Following is a brief description on the 
remaining Door calls. Servers may use 
door_revol<e to revoke access to a Door de- 
scriptor. If any requests are being currently 
handled, that request will finish, but any 
additional calls will not be honored. We 
can use the door_i nfo call to get informa- 
tion on a door-like the process ID of the 
server. The server process uses the 
door_cred call to get the user ID, group ID, 
and process ID of the calling process. We 
can use the door_server_create call when 
the default thread creation needs to be 

Listing A; Caent and server using Doors 



modified by the server. The man page 
gives a very good example on the server 
creating new threads for the client with a 
modified stack size. The calling process 
uses the door_bi nd call to bind to a particu- 
lar door. We can use the door_bjnd call 
when a private pool of threads is created. 
The door_unbind call is the antecedent of 
door_bi nd. This API is beyond the scope of 
this article, but it's worth exploring when 
developing ideas for actual Door servers. 

Doors example 

In Listing A, we show you two programs. 
The first is a simple server that opens a file 
descriptor and returns it to the client mak- 
ing the request. The second is a client that 
makes a request from the server for a par- 
ticular file. The given makefile compiles the 
example codes. 

The server example is a little longer than 
necessary for the basic implementation. This 
demonstrates the need for cleanup when exit- 
ing. First, the server creates a thread to handle 
all signals. When the server process receives a 
signal to terminate, the server must close the 
stream from the file system before exiting. 
The stream must be closed so that the entry 
point can be reused when the server is re- 
started. 

The server implementation is simple. 
The server calls door_create with the DoWork 



Listing: Makefile 



CC = gcc 

LIBS = -Ipthread -Idoor 
PROGS= s c 

all: $(PROGS) 

client. o: client. c 
$(CC) -c client. c 

server. o: server. c 
$(CC) -c server. c 

c: client. 0 

$(CC) -0 c client. 0 $(LIBS) 

s: server. 0 

$(CC) -0 s server. 0 $(LIBS) 

clean: 

riii -rf *.o s c 



Listing: Mydoor.li 



#ifndef MYDOOR 
#define MYDOOR 

#ifdef cplusplus 

extern "C" { 
#endif 

#define DDSTREAM "DoWork" 

#ifdef cplusplus 

} 

#endif 

#endif /. MYDOOR */ 
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Listing: caent. 



'.c 



#jnclude 
#1 nclude 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#i nclude 



<stdi 0 . h> 

<string.h> 

<door.h> 

<pthread.h> 

<thread.h> 

<errno.h> 

<sys/types.h> 

<sys/stat . h> 

<fcntl.h> 

<sys/time.h> 



#include "mydoor.h" 

static const ctiar* ddstream = DDSTREAM ; 
int 

main(int argc, char *«argv) 
{ 

/* Vans */ 

int dd = 0 ; /* Doors descriptor */ 
int ret_val = 0 ; /* return values from 
functions */ 

door_arg_t d_args ; 

char results[1024] ; 

int fd ; 

char message [ 128 ] ; 

strcpy ( message, "Inside Solaris!\n" ) ; 

dd = open ( ddstream, 0_RDONLY ) ; 

if ( dd < 0 ) 

{ 

fprintf ( stderr, "Error in opening a door- 
server descriptor: %d\n", 
errno ) ; 
exit ( -1 ) ; 



d_args.data_ptr = NULL ; 
d_args.data_size = 0 ; 
d_args.desc_ptr = NULL ; 
d_args.desc_num = 0 ; 
d_args.rbuf = results ; 
d_args.rsize = sizeof(results) ; 

ret_val = door_call(dd, &d_args); 
if ( ret_val != 0 ) 
{ 

fprintf ( stderr, "Error in 
door_call to door descriptor: %d\n", 
errno ) ; 
exit ( -1 ) ; 



fd = d_args.desc_ptr- 
>d_data.d_desc.d_descriptor ; 
pri ntf ( "desc_ptr=%x, desc_num=%d fd=%d\n", 
d_args.desc_ptr, d_args.desc_num, fd) 



write(fd, message, 
close ( fd ) ; 



strlen(message) ) 



/* close the door */ 
close ( dd ) ; 
return (0); 



} 



Listing: Server.c 



#i nclude 
#include 
#tnclude 
#include 
#include 
#i nclude 
#i nclude 
#i nclude 



<stdio.h> 

<door.h> 

<pthread.h> 

<thread.h> 

<errno.h> 

<sys/types.h> 

<sys/stat .h> 

<fcntl.h> 



#include "mydoor.h" 

static const char* ddstream = DDSTREAM ; 

/* Close Door on File System */ 
void 

CloseTheDoor (int sig) 
{ 

fdetach ( ddstream ) ; 
exit ( -sig ) ; 

} 

/* Signal handler •/ 
void * 

sighandle (void *arg) 
{ 

struct sigaction sigact ; 
arg = NULL ; 

/* With signals we can handle we will clean up */ 

/. SIGINT ./ 

sigact. sa_f lags = 0 ; 

sigact. sa_handler = CloseTheDoor ; 

sigemptyset ( &sigact.sa_masl( ) ; 

sigaddset(&sigact.sa_masl(, SIGINT) ; 

sigaction ( SIGINT, &sigact, NULL ) ; 

/. SIGTERM ./ 

sigact. sa_f lags = 0 ; 

sigact. sa_handler = CloseTheDoor ; 

sigemptyset ( &sigact.sa_mask ) ; 



Listing: Server.c (continued) 



sigaddset(&sigact.sa_mask, SIGTERM) ; 
sigaction { SIGTERM, Ssigact, NULL ) ; 

/* SIGQUIT ./ 
si gact . sa_f lags = 0 ; 
sigact.sa_handler = CloseTheDoor ; 
sigemptyset ( 8,sigact.sa_inasl< ) ; 
sigaddset(&sigact.sa_mask, SIGQUIT) ; 
sigaction ( SIGQUIT, &sigact, NULL ) ; 

sigignore(SIGPIPE) ; 
sigignore(SIGHUP) ; 
sigignore(SIGABRT) ; 

fori;;) 
( 

sleep! 10000 ) ; 

} 

return ( (void *) NULL ) ; 

} 



/• Work function provided by the server •/ 
void * 

DoWork (void *cookie, char *argp, 

size_t arg_size, door_desc_t •dp, size_t n_desc) 

{ 

int fd ; 

door_desc_t darray[1] ; 
int n ; 

fd = open( "server.dat", Q_RDWR I 0_CREAT I Q_TRUNC, 
0G00); 

printt ( "In DoWork: getting Id for client. \n" ) ; 

darray[0].d_attributes = DOQR_DESCRIPTOR ; 
darray[0].d_data.d_desc.d_descriptor = id ; 

door_return (NULL,0,darray,1 ) ; 
return ( (void .) NULL ) ; 

} 

int 

niain(int argc, char **argv) 
{ 

/* Vars */ 

int dd = 0 ; /• Doors descriptor */ 
FILE .fd ; 

int ret_val = 0 ; /* return values from functions 

*/ 



sigset_t set ; 

pthread_attr_t detached_attr ; 

/* make signal handler thread detached */ 
pthread_attr_init ( &detached_attr ) ; 
pthread_attr_setdetachstate( &detached_attr, 
PTHREAD_CREATE_DETACHED ) ; 

do 

{ 

errno = 0 ; 

pthread_create(NULL, &detached_attr, 
sighandle, NULL) ; 

} whi le ( errno == EAGAIN ) ; 

/* 

Block all signals in the main thread. Any other 
threads created 

by the main thread will also block all signals 
./ 

sigfillset(&set) ; 

pthread_sigmask(SIG_SETMASK, &set, NULL) ; 

/* Make sure we have a file to use as a 
interface to the server •/ 

if ( (Id = fopen ( ddstream, "w+" )) == NULL ) 
( 

fprintf ( stderr, "File creation for doors 
interface fai led: %d\n", 
errno ) ; 
exit ( -1 ) ; 

} 

else 
{ 

fclose ( fd ) ; 

} 

dd = door_create ((void*)DoWork, NULL, 0 ) ; 

ret_val = fattach ( dd, ddstream ) ; 

if ( ret_val 1= 0 ) 

{ 

fprintf ( stderr, "Error in fattach to door 
descriptor: %d\n", 

errno ) ; 
exit ( -1 ) ; 

} 

/* Wai t forever */ 
whi le ( 1 ) pause ( ) ; 



return (0); 

} 
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function pointer and then attaches the Door 
descriptor to the file system and waits forever. 

Also, the client's implementation is just 
as simple. The client opens the server's ex- 
ported file entry point, uses that descriptor 
from the open system call as the Door de- 
scriptor, and calls door_ca 1 1. When the call is 
finished, the client continues with the result 
in the pre-allocated buffer. 

Conclusion 

In this article, we provide a brief over- 
view on how Doors works, a brief de- 
scription of the API, and an example us- 
ing it for a simple server and client. In 
conclusion, the Doors API is the fastest 
IPC available by Sun on Solaris. Doors 
makes it simple to develop multithreaded 
servers. This API is very flexible and is 
worth further exploration when design- 
ing fast servers under Solaris. The Doors 
concept is full of promise and is why Sun 
is one of the leaders in new and innova- 
tive ideas, but the API must be expanded 
to work over the network to be truly use- 
ful for many situations. 

At the time of writing this article, 
the API has been ported to Linux, so other 



UNIX implementation may soon follow. At 
this time, the Door IPC mechanism doesn't 
work across the network, but this is being 
addressed by Sun for future releases. Also, 
we give a special thanks to Andy Spitzer 
for his help. 

1 - B. Bershad, T. Anderson, E.Lazowska and 
H.Levy, "Lightweight Remote Procedure Call", 
ACM Transactions on Computer Systems, Vol. 
6, No. 1, February 1988, pp. 134-154. 

2 - Sun Developer Benchmarks Fall 1996 
solaris.javasoft.com/developer/news/ 
devnews/fall96/ doors.html 
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NUMERICAL COMPUTING 




Numerical computing in Solaris 



by Paul A. Watters 

Have you ever written a numerical 
simulation using C that produces 
widely variable results when one or 
two parameters have been slightly tweaked? 
Does your database produce historical re- 
ports based on a C module that greatly over- 
estimates the profitability of your clients' 
business interests? Many of us have made 
simple errors in numerical computing with 
C in the past, particularly those involved in 
floating-point computations. Unfortunately, 
these errors can sometimes adversely affect 
the desired outcomes for applications, with 
extra debugging efforts that often inflate 
programming costs. 



Know thy enemy 



The success of numerically-intensive pro- 
grams written by computing profession- 
als in both science and industry can be 
reasonably assured if strategies are devel- 
oped a priori to deal with anticipated and 
well-documented numerical errors. These 
strategies must often go beyond what is 
recommended in many programming 
texts (e.g., explicit typecasting of all com- 
putations involving mixed data types). In 
this article, we'll outline several compo- 
nents that you can incorporate into an 
overall strategy for numerical computing 
when using the Solaris C compiler. This 



facilitates the development of robust rauneri- 
cal applications by unplementing IEEE Stan- 
dard 754 for Binary Hoating Point Arithmetic. 

Making numerical programming easy 

The implementation of this standard makes 
numerical programming easier and ensures 
that our software meets specific quality cri- 
teria. For example, special undefined nu- 
merical quantities, such as infinity (Inf) and 
Not a Number (NaN) are available for han- 
dling run-time errors through the compiler. 
In the past, this facility has generally only 
been available in interpreted numerical lan- 
guages (e.g., Matlab). In addition, standard 
exception handlers are provided for the 
classic numerical programming errors of 
underflow and overflow. This is particu- 
larly important for complex simulations, 
such as neural network modeling, where 
a single undetected overflow error passed 
to a non-linear function could render the 
results of the entire simulation useless. 
Custom handlers can also be included to 
enhance those already provided by default 
under the IEEE standard. 

A plan of anack 

How can we ensure that floating-point er- 
rors don't ruin our programs? There are 
three main issues that you must address in 
an overall strategy. Furthermore, each issue 
must be thought through carefully before 
you embark on any project that involves 
numerical computation. The first issue in- 
volves number representation as a hard- 
ware problem, and understanding the ef- 
fects that it may have on our programs. Al- 
though number representation is clearly 
different for machines with individual op- 
erating systems and hardware, the flexibil- 
ity of Solaris being implemented on several 
hardware platforms can sometimes lead to 
confusion about the physical representation 
of numbers in each individual hardware 
platform. For example, the SPARC architec- 
ture has a high-endian representation of 
floating point numbers, while the INTEL 
platform has a low-endian representation. 
Although these differences might not appear 
to be very important at first glance (particu- 
larly for small-domain computations), if 
data is shared between computers of differ- 
ent architectures but the same operating sys- 
tem in binary format (e.g., shared database 



files), you must be careful to correctly trans- 
late individual number representations. Fail- 
ing to do so might result in an apparent (but 
incorrect) increase in monthly profits com- 
puted from such shared database records, 
for example, which could have dramatic 
consequences for our clients. 

Once the representation of numbers is 
understood, the second issue that you must 
address is how errors can arise as a result of 
the binary representation of (generally) base- 
10 floating-point numbers. Many program- 
mers explicitly declare levels of floating-point 
precision (e.g., single or double precision, and 
an extended double in Solaris, wliich occu- 
pies four 32-bit words), and feel re-assured 
that their compiler would automatically take 
care of overflow and /or underflow errors. 
This is not, however, always the case. Listing 
A on page 10 shows how easily an overflow 
error can occur in even an integer-based pro- 
gram. This program doesn't have any of the 
safeguards that should be taken for specify- 
ing integer precision, etc. The following is the 
output showing the higher exponents of two 
computed using a simple formula: 

x'1=2 

x^2=4 

x"3=16 

x"4=128 

x"5=2048 

x"6=65536 

x"7=4194304 

x''8=536870912 

x'-9=0 

x~10=0 

As you can see, the higher-order expo- 
nents are incorrectly computed as zero, 
which would have an obvious impact on 
our applications' results. Fortunately, 
Solaris has some built-in methods for deal- 
ing with these kinds of errors (including a 
capacity to trap division-by-zero errors, for 
example, which might normally result in a 
run-time core-dump). This is usually achieved 
by defining a user-specified signal handler 
using sigfpeO). 

After dealing with possible errors in 
numerical representation and processing, 
the third issue in using Solaris for numeri- 
cal computing involves optimizing our 
programming to either minimize time or 
CPU utilization, depending on local priori- 
ties. Optimization can be invoked on the 
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command line by flags such as -fast and 
-xO[l,2,3/4,5]. Many of these options can 
take advantage of SPARC and INTEL archi- 
tecture by using register variables for tempo- 
rary variables, loop unrolling, dead-code 
elimination, etc. Users can also improve 
their own coding by proper loop nesting and 
inlining function calls (which can reduce ex- 
ecution time, but increase the size of the ex- 
ecutable). Another method of optimization 
involves using the most efficient implemen- 
tation of a particular algorithm. In fact, 
many of these are available in the Solaris de- 
velopment environment, which has three 
main math libraries. These are libsunmath 
(math library), libmvec (vectorized math li- 
brary) and libcopt (optimized math library). 
Our use of these hbraries or of those pro- 
vided with Numerical Recipes, for example. 

Listing A: C source code demonstrating 
overflow error 



#include <stdio.h> 

ma1 n( ) 
{ 

int j=0, j=0, x=2, pow=2; 

for (i=0; i<10; 
{ 

for ( j=1; j<=i; j++) pow *= X; 
printf("x"%d=%d\n", pow); 

} 



will complement any of the automated opti- 
mizations that a particular compiler might 
make on our behalf. 

Conclusion 

C is often thought of as the last language of 
choice for numerical programming because 
early compilers failed to meet the same stan- 
dards that scientists and engineers, for ex- 
ample, had come to expect from formula- 
based languages such as FORTRAN. How- 
ever, the new Solaris compilers allow us to 
develop intensely numerical programs using 
a compiled, functional programming lan- 
guage with more certainty that our results 
are accurate, or at the very least, to place 
limits of the interpretability of our results. 

Further reading 

The bible of numerical computing is 
Numerical Recipes, which is now freely 
available on-line at nr.harvard.edu/nr/ 
nronIine.html. This book contains generic 
code for C, FORTRAN, BASIC, and Pascal, 
providing function libraries for computing 
almost any possible mathematical function 
in an efficient manner. ^ 



Paul A. Waiters is a research officer in the 
Department of Computing at Macquarie 
University, Australia. He has developed a 
number of numerically-intensive simula- 
tions (e.g., neural networks) using the 
Solaris development environment. 



Distnibutetl Computing 




Process distribution and load 
balancing-problems and solutions 



by H-W Schlote 

The computing power of many work- 
stations can be combined to reach the 
area of super-computing. But these ben- 
efits can be accompanied by many problems. 
In this article, weTl explore some possible 
solutions. 



In the past, super-computers were used to 
solve complex computing tasks. But, things 
have changed. Prices of middle-ranged 
workstations have fallen to very affordable 
amounts, while their computing power has 
increased nearly reaching the area of super- 



computing. Therefore, today many industries 
are substituting former super-computers 
with UNIX workstation clusters. Famous 
films such as Toy Story (computed on a Sun 
workstation farm) and Titanic (Digital UNIX 
DEC Alpha and Linux-PCs) used UNIX clus- 
ters. Another example is the RSA-contest, 
where thousands of computers worldwide 
searched for crypt-keys. 

We must classify distributed computing 
into several fields. One field is known more 
commonly by the name massive parallel com- 
puting. This means that one computer with 
dozens or even hundreds of processors use 
shared memory. Communication between 
several distributed jobs can be performed 
using toolkits like parallel virtual machine 
(PVM), or the message passing interface 
(MPl) both provided by GNU. 

In this article, the term distributed comput- 
ing refers to a software product that accepts 
requests and starts the corresponding job on 
one of many hosts in a LAN. The prerequisite 
for using distributed computing is the possi- 
bility to divide the computing task into sev- 
eral sub-tasks. 

A case Study 

The following example will show both the 
power of using many workstations together 
and the potential pitfalls. Suppose you need 
to process geographical data of a country. The 
conventional (super-computer) approach 
would be to solve the problem in one step 
using the hierarchical memory structure of a 
super-computer. 

Now, consider dividing the country into 
parts. The amount of data per computing 
task (a subtask of the main goal) is thereby 
greatly reduced, and the subtask can be 
solved by a UNIX workstation. With a load 
balancing and process distribution system, 
the several subtasks are distributed over the 
available workstations. This way, costs, time, 
and effort are significantly reduced. 

Problem: security hole 

Most load balancing and process distribu- 
tion systems must be run with superuser 
privileges. They communicate over the 
network, sometimes not only in the LAN 
but in a WAN. So, you have one more pro- 
gram running with superuser privileges 
listening on ports open to hackers all over 
the world — ^just another security hole. We 



know of only one system capable of running 
with normal user privileges — PDS. We'll 
give you a list of available process distribu- 
tion software at the end of this article. 

Problem: uncertainty 

Imagine it's Friday afternoon. There's a fi- 
nal deadline on Monday for delivering pro- 
cessed data. All your programming work is 
done and this morning you solved the last 
(known) error. The processing takes about 
two days on the 30 workstations available. 
So, you start your jobs and go home with a 
really good feeling. Unfortunately, there is 
some kernel panic or power failure (the 
cleaning personnel accidentally unplugged 
the power cord) or anything else on one of 
the machines working for you. To make it 
worse, this machine had almost finished a 
job on which lots of others depend. 

So, your whole process gets sent back 
to the beginning and you have to explain 
to your boss what happened and why you 
used the only machine that failed. You also 
have to explain why this job was running 
there, why you didn't take some other ma- 
chine, why you didn't look for the jobs on 
Saturday and Sunday etc. 

There's a possibility for you to use some 
high availability (HA) attempt to avoid such 
a problem. But you would have to build your 
network with every machine being redxmdant, 
which leads to unnecessarily high costs. What 
you want are central machines like database 
servers being built redundant (for example, a 
big Sun enterprise server with redundant 
backplane, processors, memory, interfaces, 
etc.) or mirrored with an HA attempt like 
Sun's SPARC-cluster-HAand SPARC-cluster- 
PDB. All workstations should be managed by 
a process distribution system. This needs to 
be done not only to keep up with the work 
(which is easy) if anything goes wrong, but to 
also start a failed process anew if it's impor- 
tant to you and you think that the failure Ues 
within the hardware (network, computer 
hardware, or operating system) and not 
within your software. Figure A on page 12 
shows a graphical representation of a process 
distribution system with fault management. 

Conflicts between users 
and jobs 

Often you use the same workstations as work- 
place computers and to compute distributed 
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Figure A 
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This is a process distribution system witli fault rrianagement. 



jobs. This may lead to problems if the distrib- 
uted jobs hinder the user There are multiple 
ways to avoid this kind of conflict. A good pro- 
cess distribution system should offer all possi- 
bilities as options. 

First, you can generally define that no 
processes should be run during office hours. 
This is the most effective method, but it 
wastes a lot of computing time. The typical 
Sun machine has more than one processor 
and can perform more than one job at a time. 
So why shouldn't a job run on this machine 
if sufficient memory is installed and suffi- 
cient computing power exists? 

The second way to avoid conflicts be- 
tween users and distributed jobs is to set 
the maximum number of jobs to be run on a 
machine exphcitly less than the number of 
CPUs online. Outside of office hours, the 
system can be configured to use all CPUs. 

The third approach would be to use re- 
sources more generally. That's to say, the 
job uses n CPUs, m MB RAM, d MB disk 
space etc. The process distribution system 
should try to avoid starting more jobs on a 
machine than resources that are available. 

Only the first (very strict) approach, 
wasting computing time, will guarantee 
that conflicts won't occur. The success of 
the other possibilities depends on how 
well people work together and how good 
the communication is between the differ- 
ent users. 

In our opinion, a combined approach of 
the second and third way is the best. Speci- 



fying the resources that will be needed can 
help you avoid trashing a machine by start- 
ing jobs on it that need more memory than is 
actually installed. Also, reducing the num- 
ber of jobs to be run on workplace machines 
during office hours will help you produce a 
friendly working atmosphere. 

Equal rights 

Consider that Paul is one user of a work- 
station cluster and is starting a huge num- 
ber of parallel jobs. A few minutes later 
Mary wants to start just one small job. 
How should the distribution system per- 
form in this case? First-come-first-serve 
wouldn't be well accepted by the users. 
The next time, Mary would start her job 
directly, which could possibly confuse the 
distribution system. There must be some 
tricky algorithm implemented into a good 
process distribution system. This algo- 
rithm must assure that Mary's job would 
be started immediately after Paul's first 
job finished. 

Priorities 

The process distribution system should pro- 
vide some kind of priority scheduUng. There 
are always more and less important things 
to calculate. But using several queues will 
lead to new problems. You need some kind 
of aging algorithm. A job started with minor 
priority must be executed sometime. If there 
are always jobs with higher priorities, the 
minor priority job would never be executed, 
which isn't what we want. There must be 
some algorithm increasing the priority of a 
job with time passing. 

If the process distribution system uses 
different queues for high, medium, and low 
priorities, you'd find a job with low priority 
in the high priority queue after some time. 
This is confusing. 

Another approach is to use one queue 
with priorities and have the priorities of older 
jobs eventually get higher. This method is 
straightforward and produces clear results. 

Wilicli directory to ciioose? 

Wliere wiU a distributed job be executed? 
Or more precisely: in which directory? The 
UNIX-command rsh executes the job given in 
the home directory of the user. But, if compi- 
lation jobs need to be distributed, they must 
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be started in the current directory — ^which 
must be mounted via NFS, of course. 

In a heterogeneous UNIX cluster, how- 
/ ever, even the location of home directories 
may be different. And, on each machine there 
may be some local directory with sufficient 
space available for distributed jobs that aren't 
named the same on two machines. 

There should be a way to tell the pro- 
cess distribution system in which directory 
to change for execution. Also, you should 
be able to configure the system so it knows 
how the local directories are named, pro- 
viding there's sufficient free disk space on 
each machine. 

Different classes 

There may be some software available only 
for workstations of a specific vendor's UNIX 
version. Also, there may be some job which 
needs a large amount of computing power. 

Many situations require dividing avail- 
able computers and jobs to be computed 
into classes. Good software should provide 
an easy way to do this. 



LiStiny A: Shell script wrapper for hetero- 
geneous distribution and platform dependent 
execution of programs 



#!/usr/bin/ksh 
ARCH='pvmgetarch' 

if [ ! -d $HOME/bin/$ARCH ]; then 
echo "Architecture $ARCH not supported" 
echo "" 
exi t 1 

fi 

ARCH_DIR=$HOME/bin/$ARCH 

####################################### 
# ... finally start the application ... 

cmd=' basename $0' 

case $cind in 

too ) exec $ARCH_DIR/f oo $•;; 
• ) echo "Send may not be" 

echo "started from here"; ; 

esac 



Heterogeneous clusters 

Process distribution in. heterogeneous UNIX 
clusters has one more problem: A Sun-SPARC 
executable doesn't run on a DEC- Alpha or an 
SGI workstation. Therefore, you must write a 
wrapper shell script using the pvmgetarch- 
script (included in the PVM distribution men- 
tioned earlier) to find out on which platform 
the job has started. Listing A shows a simple 
example for such a shell script wrapper. 

Available software 

Digital Equipment developed load bal- 
ancing over 15 years ago for VAX/VMS. 
Nowadays, almost every hardware ven- 
dor has his own clustering software, 
which is sometimes combined with high 
availability approaches. These solutions, 
however, are always platform-specific. 

There is some process distribution soft- 
ware for heterogeneous UNIX clusters. Some 
examples that are in the pubUc domain are 
DQS/NQS, LSF (Platform Computing, 
Canada), and PDS (SUFFIX, Germany). 

DQS/NQS works well if you don't 
need reliability in case of network instabili- 
ties or other problems. LSF, however, keeps 
working if problems occur. Yet, PDS is the 
only product that provides the ability to 
automatically restart failed jobs (contact 
pds@suffix.de). Besides, PDS doesn't need 
superuser privileges, and therefore isn't just 
another security hole in your network. 

On the other side, you can expand and 
configure LSF using shell scripts. For ex- 
ample, if you want to take the round-trip- 
time (RTT) between two hosts into account, 
you can specify it. The disadvantage of this 
approach lies with the different implemen- 
tations in the two main streams of today's 
UNIX systems. A System V ping returns 
"host is alive" per default. The BSD equiva- 
lent permanently outputs the RTT to the 
given host. In order to obtain LSF, contact 
Platform Computing, Canada, or the local 
sales office (i.e.. Science & Computing in 
Germany). 

AH available systems offer solutions to 
avoid conflicts between users and jobs and 
between several users (see the "Equal Rights" 
heading). All approaches dealing with priori- 
ties are very different. DQS/NQS doesn't 
have an aging algorithm (at least none that 
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we know of) and doesn't handle queues with 
different priorities. LSF has several queues 
with several priorities. And, PDS has a tricky 
priority-scheduling algorithm, including ag- 
ing using one queue. 

Also, LSF starts the distributed job in 
the current working directory. PDS starts a 
job either in the current working directory 
or in a directory configured within the pro- 
cess distribution system, depending on the 
user's choice (given via command line 
argument). 



H-WSchlote was born in 1969 in SoUau, 
Germany. After studying physics at 
TU Braunschweig, he worked for about one 
year for a software firm in Braunschweig. 
In 1996, H-W (known better as Harvey) 
founded his own firm, SUFFIX. Today 
SUFFIX is a group of three UNIX special- 
ists, mainly operating in air guidance and 
car navigation projects. He can be reached 
at H.Schlote@sujlfix.de. 
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Ping the Solaris Dude 



by Robert Owen Thomas 

Does something about Solaris have you 
puzzled? Ping the Solaris Dude today! 
Submit questions to robt@cymru.com. 

How to use odd 

One of the most powerful, yet least used and 
understood commands in Solaris is /usr/sbin/ 
ndd(lM). The tool ndd(lM) modifies the ker- 
nel parameters of the drivers that use TCP/ 
IP. Such drivers as /dev/tcp, /dev/ip, and 
/ dev/hme can be tuned through the use of 
the ndd(lM) command. 

One of the first and most important things 
to realize when using ndd(lM) is that you're 
modifying kernel parameters. This can be 
very dangerous business if you aren't care- 
ful, because kernel parameters can affect ev- 
erything and everyone using your system. 
Remember this kernel tuner's mantra: Don't 
tune that which you don't fully understand. 
Now, having deUvered this warning, the 
good news is that anything you change with 
ndd is only in effect until the next reboot. So, 
if something should go awry, you can reboot 
to recover. 

You can use the ndd(lM) tool as both a 
query tool and a set tool. For example, if 
you want to know if your dual-homed host 
is acting as a gateway, simply type 

ore # ndd /dev/ip ip_forwarding 
1 

So what does this output mean? Gener- 
ally speaking, a 1 means "on" and a 0 



means "off". In this case, you enable IP for- 
warding between the two networks. Now, 
let's check this on a single homed host: 

pudge # ndd /dev/ip i p_forwardi ng 
0 

Sure enough, IP forwarding is disabled. 
Next, let's try an example with ARP. Perhaps 
you're curious about the length of time an 
entry is maintained in the ARP cache? With 
the help of ndd(lM), we can find out. We try: 

pudge # ndd /dev/arp arp_cleanup_interval 
300000 

ndd(lM) reports all time values in millisec- 
onds. So, 300,000 milliseconds equates to 
approximately five minutes. 

How do I know what to tune? 

Unfortunately, the ndd(lM) main page 
doesn't exhaustively document all of the 
various tuneables for each driver. How- 
ever, ndd(lM) is in some way self- 
documenting — all you have to do is ask! 

For example. Listing A shows all of 
the TCP tunables. These are all the vari- 
ables under the /dev/tcp device driver. 
All of the variables with the second col- 
umn (read and write) are tunable. This 
doesn't mean, however, that they should 
be tuned. Remember the kernel tuner's 
mantra! Now, list out all of the variables 
for /dev/arp, /dev/ip, and /dev/udp. 
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Listing A: ah off the TCP tunable variables shown with the ndd command 
pudge # ndd /dev/tcp \? 



tcp_conn_req_max 


( read 


and 


wr1 te) 


tcp_conn_grace_period 


( read 


and 


wri te) 


tcp_cwnd_max 


(read 


and 


wri te) 


tcp_debug 


(read 


and 


wri te ) 


tcp_smal lest_nonpriv_port 


( read 


and 


write) 


tcp_ip_abort_cinterval 


( read 


and 


wri te) 


tcp_ip_abort_interval 


( read 


and 


wri te) 


tcp_ip_notify_cinterval 


( read 


and 


wri te) 


tcp_ip_notify_interval 


( read 


and 


wri te) 


tcp_ip_ttl 


(read 


and 


wri te) 


[ Output snipped due to volume. ] 









Don't be worried if you don't know what each of the variables represents. 
You'll likely never need to tune more than a select few. 

What variables should be tuned? 

Setting the value of the tunables with ndd(lM) is very easy. The -set option 
is all you need. For example, to disable IP forwarding, simply enter: 

ore # ndd -set /dev/ip ip_forwarding 0 

Instantly, IP forwarding is disabled. Watch out! Recall that this will re- 
vert to the default (enabled) at the next reboot. More on that later. 

There are several other variables that we recommend you tune. For ex- 
ample, the now infamous smurf attack relied upon hosts responding to broad- 
cast ICMP ECHO_REQUEST messages. This can easily be disabled by enter- 
ing the following: 

ore # ndd -set /dev/ip i p_respond_to_eclio_broadca5t 0 
And: 

ore # ndd -set /dev/ip i p_respond_to_address_masl(_broadcast 0 

If your host is a gateway, you may also wish to prevent directed 
broadcasts from passing through your gateway host. This can be accom- 
plished with: 

ore # ndd -set /dev/ip ip_forward_directed_broadcasts 0 

Some of the more common questions we see are related to the hme (Fast 
Ethernet) settings. Yes, ndd(lM) can help here as well. For example, if you 
wanted to force the hme driver to use only 100 Mbit/ s full-duplex, you could 
enter 

ore # ndd -set /dev/hme adv_100fdx_cap 1 
ore # ndd -set /dev/hme adv_10Ohdx_cap 0 
ore # ndd -set /dev/hme adv_10f dx_cap 0 
ore # ndd -set /dev/hme adv_10hdx_cap 0 
ore # ndd -set /dev/hme adv_autoneg_eap 0 

This tells the hme driver to set the speed to 100 Mbit/s, the duplex to 
full, and disable all other settings. The last entry, adv autoneg cap, disables 
the automatic negotiation process. 
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Making the tuning permanent 

Once you've worked out your tuning strat- 
egy, and once you've successfully and rig- 
orously tested your changes, it's time to 
make the changes permanent. This can't be 
accomplished, however, with ndd(lM). 

To make the changes permanent, you 
must add the lines to /etc/system. None- 
theless, the lines added to /etc/system are 
very close to the same arguments you've 
given to ndd(lM). 

Let's take the hme variables as an ex- 
ample. To make the changes permanent, edit 
/ etc/ system to add 

# set hme to only use 100 Mbit/s, full duplex 

# ROT. 17 June 1998 

set hme:hme_adv_1O0fdx_cap = 1 
set hme:hiiie_adv_1O0hdx_cap = 0 
set time:hme_adv_10fdx_cap = 0 
set hme:hme_adv_10tidx_cap = 0 
set hine:hme_adv_autoneg_cap = 0 



At reboot, the changes you've made with 
ndd(lM) will take effect automatically Don't 
forget to add comments to your changes in 
/etc /system. 

Conciusion 

The ndd(lM) command is a powerful tool, 
and a must for any system administrator's 
toolbox. However, use it wisely. As with any 
kernel tuning tool, it has the capability to 
cause great harm. When you use it wisely, it 
can greatly enhance the performance and 
security of your Solaris systems. 



Robert Owen Thomas is an aspiring blues 
guitarist earning his living as a UNIX and 
networking consultant. He can be contacted 
through E-mail at robt@cymru.com, or visit 
his web site at wiow.cymru.com/~robt. 




'vm -V" TIPS 



'rm 



-r file... "every administrator in the crowd already knows the rest of this story! 



Tip #1 

rm -r shotild ahuays be preceded with pwd to 
make sure you're in the right directory. Don't 
rely on your prompt to tell you. The sh com- 
mand may put you in "/" as it did me! 



lip #3 

It's not a good idea to rm -r sub-directories 
with the same name as your root-level file 
systems and directories (see Tip #2). 



lip #2 

Ahuays use the full path when running 
rm -r because if you miss the dot (".") as I 
did (rm -r . /d i r-name), you'll have to restore 
an entire file system. 



Any other rm -r tips should be E-mailed 
to: forsythe® tusco.uet so that I can 
quit making these mistakes on my own! 
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